home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 12355 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.2 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Is This Bad Coding Practice?
  5. Date: 31 Mar 1996 10:02:20 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4jmhbdINN71a@keats.ugrad.cs.ubc.ca>
  8. References: <4jgnt2$9d1@loki.tor.hookup.net> <828135115snz@genesis.demon.co.uk> <4jjqf1$6c1@loki.tor.hookup.net>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4jjqf1$6c1@loki.tor.hookup.net>,
  12. Rajendra Singh <Rajendra_Singh@msn.com> wrote:
  13. >Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
  14. >
  15. >>No, as soon as func1 returns test doesn't exist any more so you cannot
  16. >>safely access it (doing so results in undefined behaviour). Don't
  17. >>do it, even if it seems to work on your system - it will bite you, sooner
  18. >>rather than later if you're lucky.
  19. >
  20. >I was working with a company and one of the senior programmers had
  21. >this piece of code in production.  When I questioned him about it, he
  22. >says that it will always work.  I had my doubts, that's why I was
  23. >curious as to whether or not it would always work.
  24.  
  25. Of course it will always work! Once it is compiled on a particular machine,
  26. as part of a particular program, it will do its job until the end of time!
  27.  
  28. >By the way, the forementioned piece of code worked on AIX, SCO, HPUX,
  29. >and OS/2.
  30.  
  31. Because they all use stacks in similar ways.
  32.  
  33. Suppose I modified the operating system such that when I pop the stack, it will
  34. actually free a page if the stack pointer increments past a page boundary
  35. (downward growing stack, obviously). That method will no longer work. Or what
  36. if the calling code simply uses the stack for temporary storage, or calls
  37. another function before trying to access the data? What if the stack of
  38. activation records is just a dynamically allocated linked list?
  39.  
  40. **
  41. ** WHAT IF A SIGNAL HAPPENS and puts its own context info onto the stack of the
  42. ** process?
  43. **
  44.  
  45. Many UNIX OS's put the signal context information onto the process' stack.
  46. Under Linux, I can modify the processor status bits from a signal handler,
  47. because they are put into a structure _on the stack_ --- precisely where a
  48. previous local variable used to live!
  49.  
  50. That guy has no place as ``senior programmer''. Chances are he knows that it's
  51. wrong, but being the senior guy is not able to admit that he is wrong. Why not
  52. give us the e-mail address of this individual and his boss! A little
  53. disciplinary action is in order! :))
  54.  
  55. I'm graduating from CompSci and need a high paying job ASAP. This could be it!
  56. Where do you live?
  57.  
  58. I bet that the same programmer advocating this ad-hoc method will one day
  59. forget that a function he once wrote returns a pointer to a local variable, and
  60. will try to use that pointer after having called another function which
  61. clobbers the stack. Or maybe a signal handler will be called while he is using
  62. the illegal pointer! The result will be a defect that could cause all kinds of
  63. harm to profit, data, property, life, limb, user sanity... Oh boy, what a
  64. clueless moron of a senior programmer. (Is this government sector by any
  65. chance?)
  66.  
  67. It is sheer irresponsibility for a professional to willingly introduce
  68. obviously undefined behavior into production code.
  69. -- 
  70.  
  71.